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To study implementations and optimisations of interaction net systems we propose a calculus to allow 
us to reason about nets, a concrete data-structure that is in close correspondence with the calculus, 
and a low-level language to create and manipulate this data structure. These work together so that 
we can describe the compilation process for interaction nets, reason about the behaviours of the 
implementation, and study the efficiency and properties. 


1 Introduction 

Interaction nets (5] offer a visual aspect to rewriting. Analogous to term rewriting systems, a specific 
system is defined from a user-defined set of nodes (cf. terms) and a user-defined set of rewrite rules. 
Nets are then graphs built from the set of nodes and rules are graph transformations. Interaction nets are 
therefore a specific, in fact very constrained, form of graph rewriting. 

Interaction nets have been used as a programming language, an intermediate language, and as a target 
language for the compilation of other programming languages. In all these application areas, prototype 
implementations have been built to support the work, but they are often not documented. The purpose of 
this paper is to take a new look at the implementation of interaction nets. Specifically, we are interested 
in documenting the implementation process, and in particular showing a compilation of nets to a low- 
level language. We aim to build on the past experience and knowledge obtained from building other 
implementations, and make a new contribution to this investigation. Specifically, we define: a calculus 
that can represent and express results about interaction nets; a data-structure with a low-level language 
that corresponds exactly to the calculus; and a compilation of the calculus to this low-level language. 

In addition to defining the above, an important aspect of this work is the compilation of interaction 
rules: the ability to implement rules efficiently will impact greatly on an implementation. The low-level 
language is close enough to machine code that we essentially get atomic operations so that we can under¬ 
stand the cost of an interaction. From a practical perspective, we get reliable, efficient implementations 
of interaction nets from this work. In this paper we provide the foundations for this work, and point out 
a number of directions that are currently being investigated. 

A number of evaluators have been developed for interaction nets, and one of the first abstract ma¬ 
chines was given by Sousa Pinto j9j. From another direction, a graphical interpreter in 2 was proposed 
by Lippi Q and it showed an aspect of interaction nets as a visual programming tool. Some evaluators 
have been proposed towards efficient computation, called INET |2) and amineLight |[3J. Our approach 
is to build the simplest implementation model for interaction nets that we believe can be the most useful 
as well as providing the basis for more efficient (including parallel) implementations in the future. We 
shall give some evidence to support this claim in the current paper. 

The next section recalls some background material, and in Section[3]we describe the new calculus. In 
Section [4] we give the data-structure that corresponds to the calculus together with a low-level language. 
We include also some notes about the compilation of nets into the low-level language. In Section [5] we 
evaluate the work, and give some directions for future work. We conclude the paper in Section 0 
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2 Background 



In the graphical rewriting system of interaction nets (5|, we have a set £ of symbols, 
which are names of the nodes. Each symbol has an arity cir that determines the num¬ 
ber of auxiliary ports that the node has. If ar(cx) = n for cx £ £, then a has n + 1 
ports: n auxiliary ports and a distinguished one called the principal port. Nodes are 
drawn as shown in F i g u rcQ3 A net built on £ is an undirected graph with nodes at the 
vertices. The edges of the net connect nodes together at the ports such that there is Figure 1: Agents 
only one edge at every port. A port which is not connected is called a free port. Two 
nodes (a,j3) € £ x £ connected via their principal ports form an active pair, which is the interaction nets 
analogue of a redex. A rule ((a,/3) =4> N) replaces the pair (a,j 3) by the net N. All the free ports are 
preserved during reduction, and there is at most one rule for each pah - of agents. The diagram in Figure |2] 
illustrates the idea, where N is any net built from £. The most powerful property of this graph rewriting 
system is that it is one-step confluent—all reduction sequences are permutation equivalent. 

There are many possible data-structures that 
can be used to represent interaction nets, for ex¬ 
ample single or double linked graphs. Agents 
have exactly one principal port, so we can use this 
to our advantage and represent nets as a collection 

of trees, and use a simple, single linked structure. Figure 2: Interaction rules 

Computationally the cost of evaluating a net is mostly due to the cost of the rewrite step: building the 
right-hand side of the rule; connecting the new net to the old one; freeing up the left-hand side of the rule 
(agents a and /3 in the diagram in Figure [2]). 

The goal of this paper is to build an implementation model, together with a calculus, that explains 
this process and allows the study of the cost of computation. Specifically, we provide a framework where 
we can focus on the compilation of rules where we can perform the above steps in the fewest instructions. 



Xj - 
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3 Calculus 

It is possible to reason about the graphical representation of nets, but it is convenient to have a textual 

calculus for compact representation. There are several calculi in the literature, and here we review the 

Lightweight calculus (3[, which is a refined version of fill . 

Agents: Fet £ be a set of symbols, ranged over by a,/3,..., each with a given arity ar: £ —> IN. An 
occurrence of a symbol is called an agent, and the arity is the number of auxiliary ports. 

Names: Fet ,/F be a set of names, ranged over by x.y.z, etc. N and £ are assumed disjoint. Names 
correspond to wires in the graph system. 

Terms: A term is built on £ and ,/F by the grammar: t ::= x | cx(t\,... ,t n ), where x € JV, a € £, 
ar(a) = n and ,t n arc terms, with the restriction that each name can appear at most twice. If 
n = 0, then we omit the parentheses. If a name occurs twice in a term, we say that it is bound, 
otherwise it is free. We write s,t. u to range over terms, and sj, u to range over sequences of terms. 
A term of the form a(t\,... ,t n ) can be seen as a tree with the principal port of a at the root, and 
the terms t \,..., t n are the subtrees connected to the auxiliary ports of a. The term $t represents an 
indirection node which is created by reduction, and is not normally part of an initial term. 
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Equations: If t, u are terms, then the unordered pair t = u is an equation. A ranges over multisets of 
equations. 

Rules: Rules are pairs of terms written: a(x \,... ,x„) = P(yi, ■ ■ ■ ,y m ) => A, where (a,j3) £ Z x E is the 
active pair, and A is the right-hand side of the rule. All names occur exactly twice in a rule, and 
there is at most one rule for each pah - of agents. We call the free names xi,... ,x n ,y i,... ,y m in A 
parameters and write it as A(xi,... ,x n ,y 1 ,... ,y m ). All other names are bound. 

Configurations: A configuration is a pair {1%, (F | A)), where 3x8 is a set of rules, F a sequence of terms, 
and A a multiset of equations. Each variable occurs at most twice in a configuration, and we 
extend the nomenclature of free and bound names from terms. The rules set 3% contains at most 
one rule between any pair of agents, and it is closed under symmetry, thus if a(x) = j8 (y) £ 3f 
then /3 (y) = a (x) £ 3%. We use C, C' to range over configurations. We call F the head and A the 
body of a configuration. 

Definition 1 (Names in terms) The set Name(t) of names of a term t is defined in the following way, 
which extends to sequences of terms, equations, sequences of equations, and rules in the obvious way. 

Name(x) = {v}, Name(a(t\,... ,f„)) = Name(t\) U • • • U Name(t n ), Name($t) = Name{t). 

The notation t[u/x\ denotes a substitution that replaces the free occurrence of x by the term u in t. 
This extends to equations and configurations in the obvious way. 

Definition 2 (Instance of a rule) If r is a rule a(xi,....x n ) = /3 (yi,... ,y m ) => A, then A denotes a new 
generic instance of r, that is, a copy of A where we introduce a new set of bound names so that those 
new names do not overlap with others already exists, but leave the free names (parameters) unchanged. 
Example: if A is a(x,x) = ft {a), then A is (x(y,y) = [5(a), where y is afresh name. 

The configuration (38, (t A)) represents a net that we evaluate using 38', A gives the set of active 

pairs and the renamings of the net. We write (F | A) without 38 when there is no ambiguity. The roots of 

the terms in the head of the configuration and the free names correspond to ports in the interface of the 
net. We work modulo a-equivalence for bound names. The computation rules are defined below, and we 
use —>• instead of —Aub, —Aob -Ant when there is no ambiguity. 

Communication: ( u \ A,x = t,x = s ) -> C om ( u \ A,t = s ). 

Substitution: (u \ A, f(T) = u,x = s ) —> su b (u \ A, j3 (7) [s/x] = u ) where f £ E and x occurs in t. 

Collect: ( u \ A,x = s ) —>- co i ( u[s/x] \ A ) where x occurs in u. 

Interaction: ( u \ A, a{t\,... ,t n ) = f3(si,...,s m ) ) -> int ( u \ A,A r [q/xi,... ,t n /x„,si/yi,... ,s m /y m ] ) 
where a(x u ...,x„) = p(yi,... ,y„) A r £ 38. 

Example 3 Rules in Figure\3\can be represented as follows: 

Add(xi,X 2 ) = S (y) =>■ Add(xi,w) =y,x 2 = S(w), Add(xi,X 2 ) = Z =>xi =x%. 

The net in Figure [?] is represented as (r \ Add(Z,r) = S(Z)), and it is performed: 

{ r | Add(Z,r) = S(Z) ) ( r \ Add (Z,w') = Z,r= S(w') ) ^ co i ( S (W) \ Add(Z,w') = Z ) 

-hnt (s(w') | Z = W )->col(S(Z) I ). 

We define C\ -I) C 2 by C 1 —>* C 2 where C 2 is in normal form. The following theorem shows that all 
Interaction rules can be performed without using Substitution and Collect |[3| : 

Theorem 3.1 If C\ I) Ci, then there is a configuration C such that C\ -£* C —^sub^coi ^2 and C\ is 
reduced to C by applying only Communication rule and Interaction rule. □ 
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Figure 3: An example of rules and rewritings of interaction nets 

We define C\ l|j c C 2 by C\ —>'* Ci where C 2 is a {—Bnt, Aom}-normal form. Because all critical pairs 
that are generated by —>i nt and -> ro m are confluent, the determinacy property holds f3]: 

Theorem 3.2 (Determinacy) Let C\ -I). Ci- When there are configurations C',C" such that C 1 J)j c C' and 
Ci JJ-ic C", then C' is equivalent to C". □ 

3.1 Simpler calculus 

In Lightweight calculus, equations are defined as unordered pairs and configurations use multisets of 
equations. Here, in order to facilitate the correspondence between the calculus and an implementation 
model that has a code stack and an environment such as SECD-machine J6l, we introduce another refined 
calculus of Lightweight one, called Simpler calculus, by changing the definition of equations into ordered 
pair's and in configurations multisets of equations into sequences of ones. 

Terms: A term is built on E and jV by the grammar: t:: = x\ a(t\,... ,t n ) | $f. Intuitively, $t corresponds 
to a variable bounded with t (or a state such that an environment captures t). 

Equations: If t and u are terms, then the ordered pair t = u is an equation. 0 will be used to range over 
sequences of equations. 

Rules: Rules are pairs of terms written: a(x \,... ,x„) = j8(yi,... ,y m ) =4> 0. 

Configurations: A configuration is a pair (Sf, fit | 0)), where 0 is a sequence of equations. The rules 
set 3$ contains at most one rule between any pair of agents, and it is closed under symmetry. We 
use S , S' to range over configurations. 

Definition 4 (Computation Rules) The operational behaviour of the system is given by the following: 

Varl: (u\@,x = t) —► (h | ©)[$£/*] wheretfi$s. Var2: (u \ ®,t = x) —> (u \ 0)[$f/x] where t f $s. 

Indirection 1: (ii \ 0 ,St = s) —> (u ®,t=s). Indirection 2: (u \ Q.f = $.v) —>• (u \ Q.f =.v). 


Interaction: a(x 1 ,... ,x„) = j3(yi, ... ,y m ) => ©r G 2%, then 

{u I ®,a(ti,...,t n ) = j3(si—> (it I ®,®r[ti/xi,...,t n /x n ,si/yi,...,s m /y m }). 
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To remove indirection terms, we introduce an operation remind (it is extended to sequences of terms 
and configurations in the obvious way): 

dcf d&f 

remlnd(x) = x, remlnd($f) = remlnd(f), remind??,... ,f„)) = a(remlnd?),..., remind?)). 

Example 5 We show the computation of the configuration (r | Add(r, Z) = S(Z)) in Figure [5} 

(r | Add(Z,r) = S(Z)) —> (r | Add(Z,x) = Z,r = S(x)) —> ($S(x) | Add(Z,x) = Z) 

—> ($S(jc) | Z=x) —► ($S($Z) |). 
remind{% S($Z) |) = (S(Z) |). 

These rules correspond directly to the graphical data-structure and operations given in the next sec¬ 
tion. Indirection is introduced so that the data-structure manipulations can be kept simple. However, 
there is an overhead of dealing with indirection nodes. Computationally the interaction rule is the most 
expensive: the other rules will turn out to be implemented with a small number of instructions or will be 
equivalences in the data-structure. 

3.2 Expressive power 

We compare the expressive power of Simpler and Lightweight calculi. We define a translation of configu¬ 
rations from Simpler calculus into the Lightweight one as: ToLight((f| 0)) = f (remind)?) | remlnd(0)). 

Lemma 6 Let Si and Si be configurations such that Si —> S 2 . When it is by Indirectionl or Indirection2 
rules , ToLight(Si) = ToLight(Si ). Otherwise, ToLight{S\) —> ToLight(S2). 

Proof. In the case of Varl: Si = (m | 0,x = t) —> (u | 0)[$f/jt] = Si- When we assume ToLight(Si) = 
(u' | 0',x = t'), then ToLight(S 2 ) = (u 1 \ &)[t'/x], and thus ToLight(Si) -tcom ToLight(S 2 ) or ToLight(Si) 
-hiub ToLight(S 2 ). □ 

Every equation is reduced by a rule in Simpler calculus, the following holds: 

Lemma 7 When S| JJ. ( u \ 0), then 0 is empty. □ 

We define a translation of configurations ToSimple from Lightweight calculus into Simpler ones: 
ToSimple? | A)) = {t | 0) where 0 is a sequence that is the result of fixing an order of the multiset A. 

Theorem 3.3 Let C be a configuration in Lightweight calculus. When there is a configuration S in 
Simpler one such that ToSimp!e[C) IJ. S, then C JJ- ToLight(S). 

Proof. Assume S = (u | 0), and then 0 is empty by Lemma|7] Since ToLight? |) is a normal form, 
C JJ- ToLight(i7 |) by Lemma[ 6 ] □ 

Theorem 3.4 Let Ci and C2 be configurations in Lightweight calculus such that C\ JJ-i c C 2 . Then there is 
a configuration S in Simpler one such that ToSimple{C\) JJ. S and Ci JJ- ToLight(S). 

Proof. If ToSimple(Ci) has no normal form, corresponding to an infinite reduction sequence from 
ToSimple(Ci) we can construct an infinite reduction sequence starting from C\ by Lemma[ 6 ]since each 
reduction produces at most one equation such as $t = s or t = $s. This contradicts the assumption of this 
theorem. There is, thus, a configuration S such that ToSimple(Ci) JJ. S. By Theorem l3.4I Ci JJ. ToLight(S), 
and thus there is a configuration C 3 such that Ci JJ.; C C 3 and C 3 JJ- ToLight(S') by Theorem 13. 11 By the 
assumption Ci JJ-i c C 2 and the determinacy (Theorem 13.21) . C 3 = C 2 . □ 

We define a configuration of our abstract machine state by the following 3-tuple (E | 7 0), where 

• E is an environment, which is a subset of jV x 8? (lL is a set of names, 8F is the set of terms), 
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• T is an interface, which is a sequence of terms, 

• 0 is a sequence of equations to operate. 

In contrast to the SECD machine |[6j], the stack S, the environment E and the control C in the machine 
correspond to the term sequence f, the map E, and the equation sequence 0 in this abstract machine 
respectively. There is no element corresponding to the dump D in SECD machine because, during an 
execution of a rule, other rules are not called. To manage the environment, we define the following. 

Definition 8 (Operations for pairs) Let P be a set of pairs. 

dcf 

• We define a map P as a set of pairs: P(«) = m if(n,m) € P, _L otherwise. 

• We use the following notations to operate maps: 

- P(n):=T as a set (P — {(n,m)}) for any m, 

— P(«):=»; as a set (P[«] := _L) U{(n,m)}). 

We give the semantics of the machine as a set of the following transitional rules of the form (E | u \ 
0) =>■ (E' | u | 0') by applying in the order from A to C2: 

A: (E | u | 0,a(f) = j3(s)) => (E|m|0,©i) where (| a(f) =/3(s))—>• (| ©i) 

Bl: (E(x) = _L | it | 0,x = t) (E(x) := t \ u | 0) 

B2 : (E(x) = _L j m j 0,t = x) => (E(x) := t j u j ©) 

Cl: (E(x) = s | u | ©,x = t ) =4> (E(x) := T | u \ ®,s = t ) 

C2 : (E(x) = s | u | ©,t = x) => (E(x) := T | u \ 0,t = s) 


Intuitively, the rule ‘A’ corresponds Interaction rule, ‘Bl’ and ‘B2’ correspond Varl and Var2, and 
‘Cl’ and ‘C2’ correspond Indirectionl and Indirection2. To force captured terms in the environment to 
be replaced when the execution is finished, we define Update operation: 


Update(EU {(x,s)} | m | ©) 
Update)® | u \ ©) 


J Update(E[s/x] | u[s/x] \ ©[s/x]) (whenx occurs in E,n or 0) 
( Update(E | u | 0,x = s) (otherwise) 

(« I 0) 


Example 9 A configuration (r \ Add(Z,r) = S(Z)) which represents the net in Figure [7] is performed: 
(0 | r | Add(Z,r) = S(Z)) =>• (0 | r \ Add(Z,x) = Z,r = S(x)) ({(r,S(x))} | r \ Add(Z,x) =Z) 

({(r,S(x))} |r|Z=x) => ({(r,S(x)),(x,Z)} | r \ -). 

Update( {(r, S(x)), (x, Z)} | r \ -) = Update( {(r, S(Z))} | r \ -) = Update (0 | S(Z) | -) = (S(Z) |). 


4 Data-structures and language 

Here we give a low-level language, called LLO, which de¬ 
fines a set of instructions to build and reduce a net to normal 
form. The concrete representation of a configuration can be 
summarised by the diagram shown on the right, where F rep¬ 
resents the net, EQ a stack of equations, and I an interface. 

For a net, we need two kinds of graph element: agents 
and names nodes. Each of these is allocated memory in the heap. An element, such as an agent, may 
contain pointers to other elements (representing auxiliary ports). An agent can be coded in C as follows: 

typedef struct Agent { 

int id; struct Agent *port []; 

} Agent; 
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Instruction 

#agent (X\ : p \, ■■■ ,a n : p„ 
I=mklnterface (n) 
x=mkAgent (id) 

x=mkName() 
free(x) 
x\pl=y 
x[0]=a 
push(x,y) 
stackFree () 


Description 

Declare oq, • • • , a n as symbols of agents whose arity are pi,-- - ,p„- 
Create a fixed n-size interface and assign its pointer to the variable I. 

Allocate (unused) memory for an agent node whose id is id and assign it to the 
variable x. 

Allocate (unused) memory for a name node, and assign it to the variable x. 
Dispose of just an assigned allocation x of a graph element (not recursively). 
Assign a graph element y to a port p > 0 of an agent node x. 

Change the id of an agent node x into a. 

Create an equation of two graph element x,y in the stack of equations. 

Dispose of the top element of the equation stack. 


Figure 4: Instructions of LLO 


In this Agent structure, each symbol oq,..., a„ for agents is distinguished by a unique id. The length 
of port corresponds to the number of auxiliary ports of an agent. The stack of equations EQ is initially 
empty. Intuitively, an element of this stack can be written using the following code fragment in C: 

typedef struct Equation { 

Agent *al; Agent *a2; 

} Equation; 

The interface I is a node arrays of fixed size n as the size of the observable interface of a net can be 
pre-determined (and it is preserved during execution). By using LLO, we encode Simpler calculus. 






a 








Building nets. Graph elements, the stack of equations EQ and the interface I are managed by instruc¬ 
tions as shown in Figure 0] The port numbers start from 1, and by using the instruction x [/;] =y, we can 
assign a graph node y into a port p > 0 of a graph node x. We also use the port 0 to refer to the id of an 
element. For instance, x [0] =a changes the id of an agent node x into a. 

Here, we build terms in Simpler calculus. To assign an arity to an agent, we use the 
following declaration: #agent oq : p\, ■ ■ ■ , a n : p n , where /;, is the arity for an agent 
symbol a, such that ar(a ,) = p,. After this declaration, a symbol a,- can be represented 
by a unique number and an agent’s arity p, can be referred to by arityfa,) = /;,. We draw an agent node 
a of arity 3 as shown the right above figure. 

Name nodes are graph elements whose id is denoted by the symbol N and the arity 
is 0. We also use indirection nodes by $ and the arity is 1. We assume that N and $ are 
selected from a set that does not overlap with the set of agent symbols. To allocate an 
agent node whose id is id to a variable x, we use the following instruction: x=mkAgent (id) . A name node 
is allocated by x=mkName (). An assigned allocation a of a graph element is disposed of (not recursively, 
just one node) by using free (a). 

A connection between a principal port and an auxiliary port is encoded by an assignment. In this 
language, to assign a pointer of an existing graph element b to a port p of another graph element a, we 
use the following instruction: a [/;] =b. We note that the index of these ports start from 1. For instance, a 
term Add(Z,r) is encoded as shown below, together with the graphical representation. 




$ 




1. #agent Z:0, Add:2 

2. aAdd=mkAgent(Add) 

3. aZ=mkAgent(Z) 

4. aAdd[1]=aZ 


5. r=mkName() 

6. aAdd[2]=r 


Z 

T 

N 

r 


Add 

l 

T 
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Generally, when agent nodes are connected together, they are trees that we represent in the 
following way, where the free ports arc at the top of the tree. 

The stack of equations EQ is initially created empty. An equation node can point to 
two graph elements. To create an equation of two graph elements ci\,ci 2 in the stack EQ, 
we use the instruction: push (a | ,ai)- To pop an equation from the top of the stack EQ, 
we use the instruction: stackFreeQ. We represent a connection between principal 
ports by creating an equation between the two agent nodes into the stack. 



ports, we assign one name node to two ports. 



Figure 5: Representation of (i 
Add(Z ,r) = S(w), Add(Z,w) = S(Z)) 


1. #agent Z:0,S:1,Add:2 

2. /*interface*/ 

3. I=mklnterface(1) 

4. /*Add(Z,r)*/ 

5. aAdd=mkAgent(Add) 

6. aZ=mkAgent(Z) 

7. aAdd[1]=aZ 

8. r=mkName() 

9. aAdd[2]=r 

10. /*S(w)*/ 


11. bS=mkAgent(S) 

12. w=mkName() 

13. bS[1]=w 

14. /*Add(Z,r)=S(w)*/ 

15. push(aAdd,bS) 

16. /*Add(Z,w)*/ 

17. aAdd=mkAgent(Add) 

18. aZ=mkAgent(Z) 

19. aAdd[1]=aZ 

20. aAdd[2]=w 


21. /*S(Z)*/ 

22. bS=mkAgent(S) 

23. bZ=mkAgent(Z) 

24. bS [1]=bZ 

25. /*Add(Z,w)=S(Z)*/ 

26. push(aAdd,bS) 

27. /*interface*/ 

28. I [1]=r 


Defining interaction rules. We introduce rule procedures to perform interaction rules. For an interac¬ 
tion rule between a(x) and /3 (y) we define a rule procedure using the syntax: rule a /J {...} and we 
write instructions between the brackets { and } (rule block). In execution, the procedures provide special 
variables L,R that are pointers to the left and the right-hand side agents of the active pair equation. Vari¬ 
ables used in the instructions are only visible within the rule procedure. Generally, these rule procedures 
are represented as transformations on the data-structure. For instance, the rule between Add and Z given 
by AddU], jct) = Z =>■ x\ = vt is represented using the following procedure: 

1. rule Add Z { 3. push(L[1] ,L[2]) 5. free(R) 

2. stackFreeQ 4. free(L) 6. } 


The following illustrates transformations that will be applied by the rule procedure given above. 
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Figure 6: Computation rules for name and indirection nodes 



In order to manage equations in the Simpler calculus, we need mechanisms that perform rules Varl, 
Indirection! and so on. Figure [6](a) and (b) are instances of Varl and Indirection! rules to illustrate this. 


Compilation of Simpler calculus into LLO. Here we introduce a translation of Simpler calculus into 
LLO. We use a set of pairs and operations for the pairs defined in Definition [ 8 ] We also use a notation for 
strings. We write “ and ” as a pair of delimiters to represent a string explicitly. We use the notation {x} 
in a string as the result of replacing the occurrence {x\ with its actual value. For instance, if x = “abc” 
and y = 89 then “l{x}2{y}” = “labc289”. We use + as an infix binary operation to concatenate strings. 

Definition 10 (Compilation of terms and nets) Here we defined our compilation schemes that will gen¬ 
erate LLO for a given interaction net system. 

• We use a subset N of .A' x Str (jY is a set of names) so that a name x € JV can correspond to a 
string of a variable name in a code sequence and those correspondences can be looked up from 
compilation functions. We also use two operations N (x) := _L and N(x) := str for str S Str as 
defined in Definition [S] We define a function makeN to make such a set N and a code sequence for 
those names by a given name set {x\ ,..., x,, }. The function freshStr() returns afresh name. 

makeN({x\,...,x n }) = f makeN\{x\,... ,x„},0); 

makeN’({xi 1 ...,x„}N) = /et No=0; 

a\ = freshStr(); <?i = “{ai}=mkName()Ni = (No(xi) := ai );-• • 
a„ = freshStr(); c n = “{a„}=mkName () ”; N„ = (N„_] (x„) := a n ); 
in (ciH-hc„,N„) end; 


• We define a translation Compi le s from a symbol set £ into a code string as follows: 
Compile ; s (0) = f 

def 

Compile x ({a l ,....a n }) = 


“#agent ”+ “{ai}:{ar(a i)}”4-b ",{a„}: {ar(a„)}”; 
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• A translation Compile t from a term into a code string is defined as follows: 

Compilefix.N) = f (“”,N(x)) 

def 

| Compile t (a(ti,... ,t„),N) = let a = freshStr(); c = “{a}=mkAgent ({a}) 

(ci, «i) = Comp/Ye,(fi,N); ci = c\ + “{a} [1] ={ai} 

(c n ,a n ) = Compile t (t n ,Ny, c„ = c„ + “{a} C/i] ={a„}”; 
in (c + cH-|-c„,a) end ; 

• A translation Compile, from an interface u\,..., u n into a code sequence is defined as follows: 

Compile^—, N) = f 

def 

| Compile i (m,.., i u n ,'N) = let (ci, ai) = Compile, (mi,N); c\ = c\ + “I [ 1 ] ={«i}••• 

(■ c„,a n )= Compile t (u n , N); c n = c n + “I [n] ={a n }”; 
in “I=mklnterface [?;]” +ci H-bc„ end; 

• A translation Com pi le e from an equation into a code string is defined as follows: 

def 

Compile e (t = s,N) = let (ci, a\) = Compile t (t,N ); (c2, ai) = Compilers, N); 

in ci +C2+ “push({ai},{a2}) ” end ; 

• A translation Compile es from an equation sequence into a code string is defined as follows: 

def 

Compile es (e i,...,e„,N) = Compile e (e\,N) H-h Compile e (e n ,N); 

• We define a translation Compile c . from a configuration (u \ ©) with a symbol set £ into a code 
string c as follows: 

Hpf 

CompHe c {fiL, [u |©))= let co = CompilefiY.); (ci,N) = makeN{Name{ii \ ©)); 

C2 = Compile es (®,N); C3 = Compilefit, N); 
in C0 + C1+C2 + C3 end ; 

• VVc write just Compile when there is no ambiguity. 

Example 11 Lef a configuration (r \ Add(Z, r) = S(Z)) with a symbol set {Z, S, Add} as an exam¬ 

ple. The compilation Compile c ({ Z, S, Add}, (r | Add(Z,r) = S(Z))) generates the following instructions: 


1. #agent Z:0,S:1,Add:2 

2. r=mkName() 

3. a1=mkAgent(Add) 

4. a2=mkAgent(Z) 


5. al[l]=a2 

6. al [2] =r 

7. bl=mkAgent(S) 

8. b2=mkAgent(Z) 


9. bl[1]=b2 

10. push(al,bl) 

11. I=mklnterface[1] 

12. I[1]=r 


Definition 12 (Compilation of rules) We define a translation Compile,, from a rule into a sequence of 
code strings as follows: 


Compile r (a(x) = p(y) => 0) = 

let 


Compile rn ((x \,... ,x„), LR, N) = 
let 


N / = Comp/7e,.„(x,L,0); N r = Compile rn (y,R,Ni); 
(ci,N) = makeN'(Name(®) — {x,y},N,); 

C2 = Compile e S (0,N); 
in 

“rule {a} {f} {” 

+“stackFree()” 

+C] + C2 

+“free(L)”+“free(R)”+“}” 
end ; 


N 0 = N; 

Nj = (N 0 (x 1 ) :={£/?} [1]); 


N„ = (N„_!(x„) := {LR} [h] ); 


end; 


Example 13 The results of Compile r (Add(x\,X2) = Z =b x\ = X 2 ) and Compile r (kdd{x\ .X2) = S(v) 
Add(xi, w) =y,x 2 = S(w)) are as follows: 
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1. rule Add Z { 

1 . 

rule Add S { 

8. 

bl=mkAgent(S) 

2. stackFreeO 

2. 

stackFreeO 

9. 

bl[1]=w 

3. push(L[1],L [2]) 

3. 

w=mkName() 

10. 

push(L[2],bl) 

4. free(L) 

4. 

al=mkAgent(Add) 

11. 

free(L) 

5. free(R) 

5. 

al [1] =L [1] 

12. 

free(R) 

6. } 

6. 

al [2] =w 

13. 

} 


7. 

push(al ,R[1] ) 




Back-end of the compilation. Here we show how these translated codes arc evaluated on the standard¬ 
ised implementation model in the C language, showing the correspondence of codes in LLO with the C 
language. 

• #agent CX\ \ p \ , , a„ : p n . For each sort of agent, we assign a unique number that is greater 

than 1. We also assign 0 to the id for name nodes. The declaration for agent symbols corresponds 
as follows: 

#define ID_NAME 0 
#define ID_cq 1 

#define ID_a„ n 
#define MAX_AGENTID n 

In addition, to manage symbols and arities, we define two arrays Symbols and Arities as follows: 

char Symbols [MAX_AGENTID+1] = "af'On"}; 

int Arities [MAX_AGENTID+1] = {1 ,p\ ,...,p n } \ 

• I=mklnterf ace («). This makes a global n- size array for the interface and corresponds to: 

#define SIZE_INTERFACE n 
Agent *1[SIZE_INTERFACE]; 

• x =mkAgent (id). This makes a variable x whose type is Agent and assigns an agent node whose 
id is id. This instruction corresponds to: Agent *x=mkAgent (id) ; 

• x=mkName(). This makes a variable x whose type is Agent and assigns an agent node whose id is 
IDJMME. Then it assigns NULL to port [0] of the x in order to be distinguished from indirection 
nodes: Agent *x=mkAgent(IDJJAME); x->port[0]=NULL; 

• free(x). This disposes of a graph node assigned to x (not recursively, just an assigned node): 
freeAgent(x); 

• x [/;] =y. This assigns a graph element y to a port p of an agent node x. The port p in LLO 
corresponds to the port p— 1 in the standardised implementation method, and thus this instruction 
corresponds to the following code: x[p — 1] =y; 

• x[0]=a. This changes the id of an agent x into a. This corresponds to the following code: 
x->id=a; 

• push(x,y). This pushes two agents onto the equation stack. This corresponds to the following 
code: pushActive(x,y) ; 

• stackFree(). This disposes of the top element of the equation stack. In the translation result, it 
occurs in rule procedures. In this implementation, the function popActive manages the index of 
the equation stack, and thus no code is required. 
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Next we manage the translated LLO instructions for rule procedures. A rule procedure in LLO such as 
“rule Alpha Beta” is encoded as a function that is named as Alpha_Beta, takes two pointers *al and 
*a2 to two elements of the equation, and creates nets according to interaction rules. The special variables 
L and R in the rule procedures are denoted as *al and *a2, and thus L [1] , L [2],..., R [1], R [2],... are 

expressed as: al->port [0] , al->port [1] ,..., a2->port [0] , a2->port [1] ,_ As an example the 

rule procedures for Add and Z and for Add and S are encoded as follows: 


1. void Add_Z(Agent *al, Agent *a2) 

{ 

4. 

Agent *w=mkName(); 

2. pushActive(al->port[0],al->port[1]); 

5. 

aAdd->port[0]=al->port[0] ; 

3. freeAgent(al); 


6. 

aAdd->port[1]=w; 

4. freeAgent(a2); 


7. 

pushActive(aAdd, a2->port[0]); 

5. } 


8. 

aS->port[0]=w; 



9. 

pushActive(al->port[1], aS); 

1. void Add_S(Agent *al, Agent *a2) 

{ 

10. 

freeAgent(al); 

2. Agent *aS=mkAgent(ID_S); 


11. 

freeAgent(a2); 

3. Agent *aAdd=mkAgent(ID_Add); 


12. 

} 


To manage these functions, we define a rule table R, which stores pointers to those functions. Here, 
for simplicity, we use the following simple matrix: 

typedef void (*RuleFun)(Agent *al, Agent *a2) ; 

RuleFun R[MAX_AGENTID+1] [MAX_AGENTID+1]; 

For instance, the above function is stored as: R [ID_Add] [ID_Z] =&Add_Z;. The run-time function eval 
is written as follows: 


1. 

void eval() { 

10. 

pushActive(alpO, a2); 


2. 

Agent *al, *a2; 

11. 

} else al->port[0]=a2; 

//Varl 

3. 

while (popActive(&al, &a2)) { 

12. 

} else if (a2->port[0] 

!= NULL) { 

4. 

if (a2->id != ID_NAME) { 

13. 

Agent *a2p0=a2->port [0]; //Ind2 

5. 

if (al->id != ID_NAME) { //Interact 

14. 

freeAgent(a2); 


6. 

R[al->id][a2->id](al, a2); 

15. 

pushActive(al, a2p0); 


7. 

} else if (al->port[0] != NULL) { 

16. 

} else a2->port[0]=al; 

//Var2 

8. 

Agent *alp0=al->port[0]; //Indl 

17. 

} 


9. 

freeAgent(al); 

18. 

} 



5 Discussion 


To examine how data structures in INET, in 2 , amineLight (the fastest evaluator) and our implementation 
affect execution speeds, we implemented a number of evaluators using the different encoding methods. 
We fix the number of ports as MAX_P0RT that is obtained during compilation, and we pre-populate the 
heap with these nodes. The fixed-size node representation has the disadvantage of using more space than 
needed, but the advantage of being able to manage and reuse nodes in a simpler way f4]]. INET and in 2 
are based on the graph calculus of interaction nets. Agent nodes are represented as C structures: 


1. typedef struct Agent { 

2. int id; struct Port *port[MAX_P0RT] ; 

3. } Agent; 

4. typedef struct Port { 

5. Agent *agent; int portNum; 

6. } Port; 


(a) INET 


(b) in 2 





















78 


An Implementation Model for Interaction Nets 


In contrast with our method, the principal ports are assigned to port [0], and connections between 
auxiliary ports are encoded as mutual links between ports of agent nodes; in INET every connection is 
linked mutually as shown in the above (a), while in 2 uses such mutual connections only for the connection 
between auxiliary ports as shown in (b). Although in 2 has been proposed before INET, in 2 can be 
regarded as a refined version of INET. We call the method to use mutual links for the connection between 
auxiliary ports undirected encoding. 


(c) Representation of x = y in amineLight 


N 


EQ 

N 



N 

X 

X 

EQ 

N 

4- 


amineLight is based on the Lightweight calculus, 
and uses names to represent connections between 
auxiliary ports, and every term is encoded by single 
links at the start of the execution. Our method, called 
directed encoding, uses single links for the connec¬ 
tion between auxiliary ports. In the case of amineLight, an equation such as x = y becomes represented 
by mutual links during execution as shown in the figure (c), while in our method, the equation preserves 
the directed encoding, thus a single link (Figure [6]). In undirected encoding method names do not occur, 
and in directed encoding method substitution for each name is performed by removing the indirected 
connection via the name locally. Thus, the implementation needs no environments for substitutions. We 
do not garbage collect, taking account of an optimisation mentioned subsequently in this section. 


The table below shows execution times in seconds for computing Fibonacci (F n ), Ackermann (A) 
and Church numerals (SJ. We see from the table that our execution times are almost similar to those of 
amineLight and thus in terms of the cost, the undirected encoding method of in 2 is the best. 



Undirected(INET) 

Undirected(in z ) 

Directed(Light) 

Directed(Simpler) 

C32 

1.58 

1.37 

1.52 

1.49 

C33 

2.62 

2.29 

2.52 

2.49 

C34 

4.37 

3.80 

4.21 

4.15 

A(3,10) 

1.77 

1.42 

1.59 

1.58 

A(3,ll) 

7.12 

5.73 

6.44 

6.39 

A(3,12) 

29.47 

24.01 

26.39 

26.14 

2 7 6 I I 

0.73 

0.71 

1.26 

1.28 

2 7 7 I I 

2.12 

2.13 

3.58 

3.68 


In comparison to amineLight, our implementation computes Fibonacci numbers and Ackermann 
function a little faster. On the other hand, amineLight performs better in the Application of Church 
numerals. The reason is that Application of Church numerals demand a lot of computation for names, 
especially for equations such as x = y, yet these operations require extra computational steps in our 
implementation. To illustrate this point, let us look at the computation of the following sequence of 
equations: a = x,y = f5,x = y. The lightweight abstract machine in amineLight reduces it to /J = a 
in two steps: ( | a=x,y = [5,x = y) —)- com ( | ct = y, y = j3) —)- com ( | a = j3), whereas our encoding 
method takes four steps: ( \ a = x, y = j3,x = y) —> ( \ a = $y,y = j3) —> (| a = y, y = /3) —> (| 
a = $/3 ) —> (| a = j3 ). This is because Lightweight calculus manages both sides of an equation, while 
Simpler one manages only a single side. To illustrate further, the table below shows ratios of name 
operations (denoted as “N”) to interaction operations (as “I”). 
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I 

Light 

Simpler 

N 

N/I 

N 

N/I 

F 32 

74636718 

51008017 

0.68 

65106325 

0.87 

F 33 

123315177 

82532797 

0.67 

105344341 

0.85 

F 34 

203654818 

133540964 

0.66 

170450820 

0.84 

A(3,10) 

134103148 

134094952 

1.00 

134094952 

1.00 

A(3,ll) 

536641652 

536625264 

1.00 

536625264 

1.00 

A(3,12) 

2147025020 

2146992248 

1.00 

2146992248 

1.00 

2 7 6 I I 

15676873 

43111255 

2.75 

64538288 

4.12 

2 7 7 I I 

46118916 

126826871 

2.75 

190190039 

4.12 



With respect to the computation of Application of Church numerals, the ratio increases to 4.12 compared 
to only 2.75 in the amineLight encoding method. Even though the cost of each operation for those names 
is quite small, as shown in the computation of Fibonacci number that is faster where the ratio increases 
by 0.18, the much accumulation of the cost induces the less efficiency. We anticipate that it is possible 
to reduce the cost of operations for names by enhancing the data-structures. 

The advantage of the directed encoding method 
is locality of the rewriting in parallel execution. An 
active pair must be reduced with the interface pre¬ 
served, and thus reduction of two active pair's that are 
connected via an auxiliary port(s) of an interacting 
agent need to be managed differently because each 
rewrite will update the same set of auxiliary ports. 

As an example take the graph shown in the right side figure, which is a graph encoded in in 1 2 3 4 of the net in 
Figure [5| The two active pairs are connected to each other via the auxiliary port of the interacting agent 
Add and Z, and this connection information must be preserved when the active pairs are reduced at once. 
This checking process could be spread into other parts of the net globally. In the case of the directed 
encoding method, the connection is preserved by a name as shown in Figure [5] and thus reduction of the 
two active pair's are performed in parallel as long as critical sections are used to manage names. 

The mutual links affect the locality and thus we have proposed the new 
method of encoding so that a connection between names can be represented 
by a single link. With respect to the encoding method in amineFight, though it 
is the directed one, the connections between names are represented as mutual 
links (Figure (c)) and we need to check for the lock and this can also spread 
globally. Take the right side figure as an example. This shows a graph after 
the first step computation of a = x, y = (5 , x = y. The two elements of the stack should not be performed 
at once because each rewriting affects another, so the checking process is also required. 

In addition, our model is simpler than the model of amineFight in terms of dealing with equations, 
thus only a single side of an equation is managed. This derives less critical sections that are caused only 
by the computational rules Varl (Figure [6] (a)) and Var2, since name nodes can be pointed-to by two 
active pairs (that is, auxiliary ports of an active pair are connected). Moreover, those are performed by 
connecting the ports of names to other principal ports of unlocked agent nodes, therefore these can be 
locked with an atomic operation such as Compare-and-swapping as follows: 



1. void evalO { 

2. Agent *al,*a2; 

3. while (popActive(&al,&a2)) { 

4. loop: 


12. } else if (!(_sync_bool_compa 

re_and_swap(&(al->port[0]),NULL,a2))) 

13. goto loop; //retry 
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We finish this section by outlining an important optimisation, but leave the implementation details 
for future work. Once a net is compiled into an instruction list of LLO, operations such as producing, 
disposing and connecting ports of agents is done at the level of execution of those instructions. We 
illustrate the optimisation by considering the rule between Add and S: Add(xi ,xf) = S(y) =4> Add(xj. w) = 
y,x 2 = S( vv). The compilation result of this rule illustrated in Example [T3l In the right-hand side of this 
rule, the active pair agents Add and S also occur. Thus, instead of producing new agents, it is possible 
to reuse the active pair agents. By introducing StackL and StackR to refer the top elements of the 
stack EQ, it is possible to obtain an alternative sequence of instructions where number of instructions, 
especially for heap allocations, decreases and thus faster execution is expected: 


1. rule Add S { 

4. 

tmpR=StackR 

7. push(x2,tmpR) 

2. w=mkName() 

5. 

St ackR=tmpR[1 ] 

8. } 

3. x2=StackL[2] 

6. 

tmpR[1]=w 



6 Conclusion 

In this paper we have designed a simple data-structure for representing interaction nets, and designed a 
corresponding calculus that has a direct relationship with the structure. As a consequence, we can use 
the calculus to reason about the rewriting process, and also to study the cost of reduction. This led to 
an investigation into optimising rules which we outlined in Section 5. We believe that this model can 
provide the basis for further development implementation technology for interaction nets. 
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